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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The present document is part 6 sub-part 2, of a multi-part deliverable covering Broadcast and On-line Services: Search, 
select and rightful use of content on personal storage systems {"TV- Any time"), as identified below: 

Parti: "Benchmark Features"; 

Part 2: "System description"; 

Part 3: "Metadata"; 

Part 4: "Content referencing"; 

Part 5: "Rights Management and Protection (RMP)"; 

Part 6: "Delivery of metadata over a bi-directional network"; 

Sub-part 1: "Service and transport"; 

Sub-part 2: "Phase 1 - Service discovery"; 

Sub-part 3: "Phase 2 - Exchange of Personal Profile"; 
Part 7: "Bi-directional metadata delivery protection"; 
Part 8: "Phase 2 - Interchange Data Format"; 
Part 9: "Phase 2 - Remote Programming". 
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Introduction 



"TV- Anytime" (TV A) is a synchronized set of specifications established by the TV- Any time Forum. TVA features enable 
the search, selection, acquisition and rightful use of content on local and/or remote personal storage systems from both 
broadcast and online services. 

TS 102 822-1 [2] and TS 102 822-2 [3] set the context and system architecture in which the standards for Metadata, 
Content referencing, Bi-directional metadata and Metadata protection are to be implemented in the TV-Anytime 
environment. TS 102 822-1 [2] provides benchmark business models against which the TV-Anytime system architecture 
is evaluated to ensure that the specification enable key business applications. TS 102 822-2 [3] presents the TV-Anytime 
System Architecture. These two documents are placed ahead of the others for their obvious introductory value. Note 
that these first two documents are largely informative, while the remainder of the series is normative. 

The features are supported and enabled by the specifications for Metadata (TS 102 822-3 sub-parts 1 [4], 2 [5], 3 [6] 
and 4 [7]), Content Referencing (TS 102 822-4 [8]), Rights Management (TS 102 822-5 sub-parts 1 [9] and 2 [10]), Bi- 
directional Metadata Delivery (TS 102 822-6 sub-parts 1 [11], 2 (the present document) and 3 [12]) and Protection 
(TS 102 822-7 [13]), Interchange Data Format (TS 102 822-8 [14]) and Remote Programming (TS 102 822-9 [15]). 
This list of features is to be used as guidance to manufacturers, service providers and content providers regarding the 
implementation of the Phase 1 and Phase 2 TV-Anytime specifications. 
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Scope 



The present document is the sixth in a series of specification documents produced by the TV -Anytime Forum. These 
documents establish the fundamental specifications for the services, systems and devices that will conform to the 
TV-Anytime standard, to a level of detail that is implementable for compliant products and services. 

Congruent with the structure initially defined by TV-Anytime, these specifications are parsed into three major areas: 
Metadata, Content Referencing, and Rights Management and Protection. Within these general areas, the following 
specifications have been developed : TS 102 822-3-1 [4], TS 102 822-3-2 [5], TS 102 822-3-3 [6], TS 102 822-3-4 [7] 
TS 102 822-4 [8], TS 102 822-5-1 [9], TS 102 822-5-2 [10], TS 102 822-6-1 [11], TS 102 822-6-2 (the present 
document), TS 102 822-6-3 [12], TS 102 822-7 [13], TS 102 822-8 [14] and TS 102 822-9 [15]. 

TS 102 822-1 [2], TS 102 822-2 [3] define the context and system architecture in which these specification shall be 
implemented. TS 102 822-1 [2] provides benchmark business models against which the TV-Anytime system architecture 
is evaluated to ensure that the specification enable key business applications. TS 102 822-2 [3] presents the TV-Anytime 
System Architecture. These two documents are largely informative documents, while the others in the series are 
normative. 

The scope of the present document comprises the delivery of TV-Anytime metadata and content referencing information 
via a bi-directional network using a PDR's return path. 

The requirements for this technology are outlined in TS 102 822-1 [2]. The following is an overview of the return path's 
use: 

• "The consumer can get more information about the programme from either the content provider or from a 
programme information service offered by a third party. This could include programme specifications (such as 
source, duration, format, storage location, etc.), programme schedules, commentary, critiques, liner notes from 
the provider or third parties, etc." 

• "A Return Path is a data connection from a consumer's home digital storage system (e.g. PDR) to one or more 
service providers. The return path gives the consumer access to interactive content, such as the Internet and 
interactive television. It also allows service providers to access consumer profile/preference information in 
order to make business decisions regarding content that is provided to the consumer." 

The present document describe the mechanism for describing and discovering IP -based web "metadata services" from 
which a client shall request metadata from, and submit user-centric data to. The present document does not address the 
unidirectional delivery of metadata over IP networks, or the delivery of content over IP networks. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

acquisition: retrieval of content 

application: specific set of functions running on the PDR 

NOTE: Some applications use metadata, either automatically or under consumer control. 

authority: organization that creates CRIDs 

bi-directional network: network that supports two way, point-to-point, one-to-many, and many-to-many data delivery 

NOTE: The Internet is an example of such a network. A PDR may access a bi-directional network using its return 
path. 

capture: storing the acquired content (e.g. to local storage) 

content: anything the viewer would like to access (movies, games, TV programmes, radio programmes, etc.) 

content creator: producers of the content 

content provider: entity that acts as the agent for and is the prime exploiter of the content 

content reference: pointer to a specific content item 

location resolution: process of establishing the address (location and time) of a specific content instance from its CRID 
locator: time and place where a content item can be acquired 

metadata: generally, data about content, such as the title, genre, and summary of a television programme 
NOTE: In the context of TV-Anytime, metadata also includes consumer profile and history data. 

metadata service: service that provides TV-Anytime data using a server on a bi-directional network 

NOTE: The formats of the data and the protocols used to deliver that data are defined by the present document. 

programme: editorially coherent piece of content 

NOTE: Typically, a programme is acquired by the PDR as a whole. 

resolving authority: body which provides location resolution 

Resolving Authority Record (RAR): information needed for retrieving the location resolution data for the given 
authority 

return path: part of the bi-directional distribution system from the consumer to service provider 

segment: continuous portion of a piece of content, for example a single news topic in a news programme 
service provider: aggregator and supplier of content which may include gateway and management roles 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ARIB Association of Radio Industries and Businesses 

NOTE: A Japanese standards organization. 

ATSC Advanced Television Systems Committee 

NOTE: American based standards organization for establishing technical standards for advanced television 
systems, including digital high definition television. 

BiM Binary format for Multimedia description streams 

NOTE: Defined in ISO/IEC 15938-1 [18] (MPEG-7 Systems part). 

DNS Domain Naming System 

NOTE: System used on the Internet to register names that can then be mapped into IP addresses using a DNS 
server RFC 1591 [1]. 

DVB Digital Video Broadcasting 

NOTE: Set of standards used for European digital TV broadcasting. 

EPG Electronic Programme Guide 

NOTE: Means of presenting available content to the consumer, allowing selection of desired content. 

HTTP HyperText Transfer Protocol 

IP Internet Protocol 

NOTE: Generic name for the network protocols used on the Internet. 

IPR Intellectual Property Rights 

PDR Personal Digital Recorder 

RAR Resolving Authority Record 

SOAP Simple Object Access Protocol 

TCP Transmission Control Protocol 

UDDI Universal Description Discovery and Integration 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

W3C World Wide Web Consortium 

WSDL Web Services Description Language 

WS-Inspection Web Services Inspection language 

XML extensible Markup Language 



4 Introduction 

The TV-Anytime Forum has defined a number of data types that can be exchanged between TV-Anytime devices. These 
include programme metadata, content referencing information, and user-centric metadata. The present document is 
concerned with data exchange between TV-Anytime clients and metadata servers over a bi-directional network using the 
return path. A TV-Anytime client is typically a PDR, although in the present document the client can be any Internet 
connected device. These devices do not necessarily need to have the ability to display or store content, since many types 
of devices can exploit TV-Anytime metadata services (e.g. a mobile phone displaying an EPG). 

Programme metadata and content referencing information can be delivered unidirectionally (e.g. via traditional 
broadcast or IP multicast) or via a bi-directional network. The reasons a TV-Anytime provider might choose to deliver 
data via a bi-directional network are as follows: 

• It allows a richer set of metadata to be delivered, since there are much lower bandwidth constraints. 
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• It allows TV-Anytime data providers without access to a broadcast system to deliver metadata to clients. 

• It allows TV-Anytime data providers to personalize the metadata they offer according to the source of the 
request. 

• It allows a range of client devices, which are not necessarily able to receive broadcast data, to access and 
exploit TV-Anytime data. For example, a mobile phone or personal organizer could use the metadata service to 
show the user an EPG. 

User-centric metadata can only be delivered from a PDR to a TV-Anytime metadata service when a return path is 
available and the user authorizes it. The submission of such user data allows the metadata service to provide a variety of 
value adding services, which are more completely described in clause 6.5 of TS 102 822-3-1 [4]. 

The present document defines the protocols that allow these transactions to take place in an interoperable fashion. Note 
that, due to the widespread nature and mass penetration of the Internet, the TV-Anytime Forum has completely specified 
the transport and network layer protocols (TCP/IP) necessary for end-to-end interoperability. This is in contrast to 
unidirectional transport mechanisms, which are not completely specified by the TV-Anytime Forum, but instead defined 
individually by the bodies responsible for the various broadcast standards used around the world (e.g. ARIB, ATSC, 
DVB, etc.). 

To use a TV-Anytime metadata service a client takes the steps illustrated in figure 1 . 




Discover 

Metadata 

Service 



Obtain 
Capability 
Description 



Exploit 

Metadata 

Service 




URL 



Metadata Service 
Capability Description 



Figure 1 : The steps in using a TV-Anytime metadata service 

These steps are described in more detail in the following three clauses (in reverse order). Note that a metadata service 
must provide a description capability (see TS 102 822-6-1 [11]) but the support for metadata service discovery (the 
present document) is optional. The middle step typically will only occur when a metadata service is first discovered or 
updated, and not each time the metadata service is used. 

4.1 Types and functionalities of Metadata services 

TV-Anytime metadata services can be broken into two basic types, which are shown in figures 2 and 3. The metadata 
services specified are all request-response based. This can be seen in the two figures - the network transaction is always 
point-to-point (client to server), and the transaction is always initiated by the client. 



4.1.1 



Metadata retrieval 



Metadata retrieval occurs when a client wishes to obtain certain metadata from a metadata service that it has previously 
discovered and obtained a capability description for. The following list gives some examples of metadata retrieval: 

• A client wishes to obtain programme reviews for a CRID. The client sends a request specifying the CRID and 
type of metadata required, and the metadata service responds with the appropriate ProgramReviewTable. 

• A client wishes to obtain the schedule information for a particular channel over the next week. The client 
sends a request specifying the channel, date range, and type of metadata required. The metadata service returns 
a ProgramLocationTable and Programlnf ormationTable corresponding to the programmes on 
that channel. 
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A client wishes to search a metadata service that specializes in movie information. The client sends a request 
specifying the type of movie (e.g. the genre is "Western" and the star is "John Wayne") and the type of 
metadata required. The metadata service returns a number of matching movies, using a 
Programlnf ormationTable and ProgramReviewTable. 



Metadata 
Service 



IP Network 



Request 




Metadata 



NOTE 1 : 



NOTE 2: 
NOTE 3: 



Any party capable of delivering compliant TV-Anytime data could provide a metadata service. Examples 

include: content creators, content providers, service providers, consumer electronics manufacturers and 

third parties aggregation services. 

The request contains parameters that specify the type of metadata required by the client. 

The types of metadata returned could be any of the non user-centric data specified in TS 102 822-3-1 [4] 

(i.e. the fragments defined in clause 4.3.1 .1 of TS 1 02 822-3-2 [5]), along with content referencing 

information. 



Figure 2: Client requesting metadata from a metadata service 

4.1 .2 Submission of user-centric metadata 

Submission of user-centric metadata offers a number of possible benefits to both consumers and metadata service 
providers. These are described in clause 5 of TS 102 822-3-1 [4]. Ensuring the privacy of these transactions and that the 
metadata service provider is trustworthy is essential to the submission of user-centric metadata. The means by which 
this is ensured is not defined by the present document. 
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IP Network 



User-centric data 




Acknowledgement 



NOTE 1 : In this case, the metadata service is a user data aggregator. Any of the parties listed for figure 2, or any 
other party capable of usefully exploiting TV-Anytime usage information in a trustworthy fashion, could 
provide the metadata service. 

NOTE 2: In principle, the user-centric data may be any of the types defined in TS 102 822-3-1 [4] 

(e.g. userPref erences and usageHistory). For the purposes of the present document only a 
submission of carefully constrained, anonymous UsageHistory instances is allowed. 

Figure 3: Client submitting user-centric data to a service provider 

4.2 Metadata service capability descriptions 

In order to exploit usefully the metadata services described in the previous clause, the client needs information about the 
nature of the metadata service being offered. This is because different metadata services will provide different types of 
metadata and can be queried in different ways. For example, some metadata services may offer just content referencing 
information, whilst others may provide programme metadata but no segmentation information. Similarly, whereas one 
server may only be able to accept simple requests for metadata based on a CRID, another server may offer much more 
sophisticated querying and sorting capabilities. Moreover, different types of queries are only useful if a client is able to 
establish sensible values with which to query. An example of this is a query for scheduling data 
(ProgramLocationTable). In order to query for scheduling information on a particular content delivery service, 
the client needs to know the content delivery services for which that metadata service has data. 

To address this issue, each metadata service provides, on request from a client, a capability description. This capability 
description allows a client to flexibly query a metadata service, without making requests that will not be supported by 
that metadata service. Furthermore, it allows metadata service providers to flexibly implement the server in a way that 
is appropriate to the data that they have available. 



4.3 Metadata service discovery 



Metadata service discovery is the process by which a client establishes a URL where a TV-Anytime metadata service 
can be found. There are a number of ways this process can occur, but only the third method (see clause 4.3.3) is 
addressed by the present document. 

4.3.1 Non-standardized discovery 

A number of methods exist for discovering the URLs of metadata services that will not be standardized by the 
TV-Anytime Forum. The following list gives some examples: 

• The client might be pre-programmed with a set of URLs that refer to one or more metadata services. This will 
typically be useful in a vertical market, or tightly controlled horizontal market. 
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• A user might manually enter a URL of a new metadata service he is interested in, using some means of text 
input. 



• 



The software on a client may be updated using software updates delivered via a unidirectional broadcast, or 
over the return channel. 



4.3.2 Unidirectional delivery of discovery information 

The System Specification [13] and Content Referencing Specification [8] define ways or requirements on the 
underlying transport, in which the URL of a bi-directional metadata and/or content referencing service can be 
discovered from TV-Anytime information inserted in a unidirectional stream. The present document defines how a client 
can usefully exploit the discovered service using the resulting URL. 

4.3.3 Client-Initiated discovery using the bi-directional network 

This mode of metadata service discovery involves using the bi-directional network to access a "Yellow Pages" of 
TV-Anytime metadata services. The mechanism is based upon W3C standards for web service discovery (UDDI [16] 
and WS -Inspection [17]), the use of which is standardized by the TV-Anytime Forum, according to the rules given in 
clause 5. Support for these discovery techniques by clients and servers is optional. 



Metadata service discovery 



The present document describes how standard web service discovery techniques can be used to allow PDRs and other 
TV-Anytime clients to discover TV-Anytime metadata services. The relevant standards are UDDI [16] and 
WS-Inspection [17], which enable different, but complementary, modes of discovery. A provider can choose to enable 
neither, both, or just one of these mechanisms. 

For a useful overview of these two standards please refer to: "The WS-Inspection [17] and UDDI Relationship [16]". 

5.1 Discovering a get_Data operation that will provide metadata 
for a certain CRID authority 

The content referencing specification describes the use of DNS SRV records to discover web services for location 
resolution, using only a CRID as the starting point. The present document defines an analogous method for use in 
discovering metadata delivery services. The form of the DNS query string is: 

_gmet._tcp.<name_extension segment from CRID authority >.<DNS segment from CRID authority>, 

where gmet is short for "get metadata". 

Since a resolution authority will not necessarily provide (directly or indirectly) a metadata service for its CRIDs, the 
client should not assume that this DNS enquiry will succeed. The result of the DNS query is a machine name 
(<hostname>) and port (<port>) that locates the metadata server. A get_Data service capable of returning at least 
one type of metadata table is offered at this URL (http://<hostname>:<port>/). 

5.2 Universal Description, Discovery and Integration (UDDI) 

UDDI [16] allows PDRs, and other clients with Internet connectivity, to discover TV-Anytime metadata services without 
the client requiring any prior knowledge of the metadata service, nor any information from a unidirectional metadata 
service. Metadata service providers may publish details of their TV-Anytime metadata service(s) to the UDDI Business 
Registry. Any client can then use a node in the UDDI Business Registry (which have well-known addresses) to browse 
and locate TV-Anytime metadata services. 

Note that version 3 of the UDDI specification is used. Clients wishing to discover TV-Anytime web services using 
UDDI must conform to the behaviour described in the UDDI specification [16]. To assist metadata service providers in 
describing and categorizing their services, the TV-Anytime Forum has registered the UDDI tModels described in the 
following clauses (see clause 1.6.4 of the UDDI specification [16] for a definition of "tModel"). 
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5.2.1 TV-Anytime web service tModels 



These tModels are used when a business publishes details of their bindingTemplate structures to indicate a web 
service compliant with the present document. Clients issuing UDDI inquiry requests can use these two tModel keys 
to find only web services that are TV-Anytime metadata services. 

5.2.1.1 TV-Anytime get_Data port tModel 

This technical model represents a get_Data port as described in clause 5.1. 

Name: TV-Anytime-org:get_Data_vlO. 

Description: TV-Anytime WSDL interface for get_Data port. 

UDDI Key (V3): uddi:TV-Anytime.org:get_Data_vlO. 

Categorization: specification, xmlSpec, soapSpec, wsdlSpec. 

<tModel tModelKey="uddi : TV-Anytime . org : get_Data_vlO "> 
<name>TV-Any time -org : get_Data_vlO</name> 

<description xml : lang="en">TV-Anytime WSDL interface for get_Data port</description> 
<overviewDoc> 

<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 

</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : wsdl" keyValue=" wsdlSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 

<keyedRef erence keyName="uddi-org : types : soap" keyValue=" soapSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 

<keyedRef erence keyName=" uddi -org : types : xml" keyValue=" xml Spec" 

tModelKey="uddi : uddi . org : categorization : types " /> 

<keyedRef erence keyName="uddi-org : types : specification" 

keyValue=" specification" tModelKey="uddi : uddi .org:categorization: types" /> 
</categoryBag> 
</tModel> 



5.2.1 .2 TV-Anytime submit_Data port tModel 

This technical model represents a submit_Data service as described in clause 5.2. 

Name: TV-Anytime-org:submit_Data_vlO. 

Description: TV-Anytime WSDL interface for submit_D at a port. 

UDDI Key (V3): uddi:TV-Anytime.org:submit_Data_vlO. 

Categorization: specification, xmlSpec, soapSpec, wsdlSpec. 
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<tModel tModelKey="uddi : TV-Any time . org: submit_Data_vlO"> 
<name>TV-Anytime-org : submit_Data_vlO</name> 

<description xml : lang="en">TV Anytime WSDL interface for get_Data port</description> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org: types :wsdl" keyValue="wsdlSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 
<keyedRef erence keyName="uddi-org : types : soap" keyValue=" soapSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 
<keyedRef erence keyName=" uddi -org : types : xml" keyValue=" xml Spec" 

tModelKey="uddi : uddi . org : categorization : types " /> 
<keyedRef erence keyName="uddi-org : types : specification" 
keyValue=" specification" tModelKey="uddi : uddi . org : categorization : types "/> 
</categoryBag> 
</tModel> 



5.2.2 TV-Anytime categorization tModels 



These tModels allow a metadata service provider to categorize their services. The metadata service provider assigns 
the categories at the point of publication (see clause 5.2.3). This enables clients to issue more refined UDDI searches for 
metadata services. By categorizing a metadata service as richly and accurately as possible, a metadata service provider 
maximizes the possibility of the metadata service being discovered using UDDI. 

Use of these taxonomies is optional, and for many services it will not be appropriate to use some of the taxonomy types. 
For example, a metadata service that does not provide schedule information will not be able to use the TV-Any time- 
org : serviceURL taxonomy to list the services for which it provides metadata. 

These taxonomies do not make strong guarantees about the behaviour of any services that use them. For example, a 
service categorized as providing information on "example.com" CRIDs may only have data on some subset of them. A 
get_Data request to that service could fail to provide information on a particular "example.com" CRID. Similarly, a 
service categorized as providing German language metadata could return some of its metadata in other languages. 
Metadata service providers should sensibly categorize their services in a way that will enhance their discovery without 
creating false expectations in the client. It is always the capability description that provides the definitive description of 
the features supported by a particular operation. Therefore, having discovered a metadata service, a client should always 
retrieve a capability description of that service. In some cases, this involves no extra steps as the capability description 
will be included inside the bindingTemplate for that operation. 

All of the following tModels are categorization tModels and are unchecked. 

5.2.2.1 TV-Anytime authorityName categorization system 

The authorityName tModel is used to represent the resolution authorities of the CRIDs for which this metadata 
service provides TV-Anytime information. To establish whether content referencing information or metadata is available 
for the authority, the tableType tModel may be used (see clause 5.2.2.2). 

Name: TV- Anytime-org: authorityName. 

Description: Category system for the resolution authorities handled by a metadata service. 

UDDI Key (V3): uddi:TV -Anytime. org:authorityName. 

Valid values: A valid value is a valid resolution authority name, as defined in the Content Referencing 

Specification [8]. 

Example usage: A client searches for TV-Anytime metadata on CRIDs from a particular resolution authority. 
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<tModel tModelKey="uddi : TV-Anytime . org: authorityName"> 
<name>TV-Anytime-org : authorityName</name> 

<description xml : lang="en">Category system for the resolution authorities handled by 
a metadata service</description> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
keyValue=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi . org : categorization : types" /> 

</categoryBag> 
</tModel> 



5.2.2.2 TV-Anytime tableType categorization system 

The tableType tModel is used to represent the types of metadata table that this metadata service is capable of 
providing. 

Name: TV-Anytime-org:tableType. 

Description: Category system for the metadata table types available from a metadata service. 

UDDI Key (V3): uddi:TV-Anytime.org:tableType. 

Valid values: A valid value is a table type that can be used in the ProgramLocationTable and 

Programlnf ormationTables element returned by the describe_get_Data 
operation. 

Example usage: A client requires a certain type of metadata (e.g. segmentation information) about a programme. 

<tModel tModelKey="uddi : TV-Anytime . org: tableType"> 
<name>TV-Anytime-org : tableType</name> 

<description xml : lang="en">Category system for the metadata table types available 
from a metadata service</description> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
key Value=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org:categorization: types" /> 

</categoryBag> 
</tModel> 



5.2.2.3 TV-Anytime serviceURL categorization system 

The serviceURL tModel is used to represent the content delivery services (e.g. channels) for which this metadata 
service provides TV-Anytime information. 

Name: TV-Anytime-oig: serviceURL. 

Description: Category system for the content services handled by a metadata service. 

UDDI Key (V3): uddi:TV-Anytime.org:serviceURL. 

Valid values: A valid value must comply with the rules defined in TS 102 822-3-1 [4] for the serviceURL 

element in the Servicelnf ormationTable. 



ETSI 



1 7 ETSI TS 1 02 822-6-2 V1 .3.1 (2006-01 ) 

Example usage: A client searches for TV-Anytime scheduling information on a particular content service. 

<tModel tModelKey="uddi : TV-Anytime . org: serviceURL"> 
<name>TV-Anytime-org : serviceURL</name> 

<description xml : lang="en">Category system for the content services handled by a 
metadata service</description> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
key Value=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org:categorization: types" /> 

</categoryBag> 
</tModel> 



5.2.2.4 TV-Anytime genre categorization system 

The genre tModel is used to broadly classify the types of programmes for which this metadata service provides 
TV-Anytime information. This tModel is intended to classify metadata services providing specialist information, and 
will not be useful for metadata services that describe a wide range of programme types (e.g. broadcasters' metadata 
services). 

Name: TV-Anytime-org:genre. 

Description: Category system for the genre of programmes handled by a metadata service. 

UDDI Key (V3): uddi:TV -Anytime. org:genre. 

Valid values: A valid value is a fully qualified term (classification scheme URN and term), as defined in 

annex B of TS 102 822-3-1 [4]. Note that aliases cannot be used since a UDDI registry has no 
knowledge of any CSAlias elements from which the full classification scheme name can be 
deduced. 

Example usage: A client searches for a TV-Anytime metadata service that specializes in movie information. 

<tModel tModelKey="uddi : TV-Anytime . org : genre"> 
<name>TV-Anytime-org : genre</name> 

<description xml : lang="en">Category system for the genre of programme handled by a 
metadata service</description> 
<overviewDoc> 
<overviewURL useType="text "> 

http: //Location_At_ETSI_WebSite/FileName_for_TS102 82 2-6-2 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
keyValue=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org:categorization: types" /> 

</categoryBag> 
</tModel> 
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5.2.2.5 Other categorizations 



The Universal Business Registry provides other categorizations that may be useful in describing TV-Anytime metadata 
services (e.g. uddi-org:general_keywords). The use of such categorizations should, in general, follow the rules defined 
by the particular tModel, but TV-Anytime provides guidance for use of the 

uddi:ubr.uddi.org:categorization:geo3166-2 tModel. Namely, the assigned keyValue should categorize the 
region(s) where the programmes described by that metadata service are available. For some types of content distribution 
mechanisms (e.g. via the Internet) such a categorization will not be appropriate. 

Categories may be grouped together, as described in clause F.2 of the UDDI specification [16]. 

5.2.3 Publishing a TV-Anytime metadata service 

A TV-Anytime metadata service provider can publish details of their service to any node in the UDDI Business Registry. 
The manner in which this is done will depend upon the operator of that node (see the UDDI specification [16]). 

An example of the publication process can be found in annex A. 

A businessService is created for each metadata service that needs to be registered by that business. The 
businessService element contains a bindingTemplate for each of the bindings offered by that metadata 
service (e.g. get_Data or submit_Data). 

When publishing a get_Data operation, it is recommended that: the instanceParms element (inside the 
tModellnstancelnf o) contains a capability description. This allows the client to acquire the capability description 
of the metadata service (and so determine its usefulness), without having to issue a describe_X request. Since the 
size of the instanceParms element is restricted, the capability description will sometimes need truncating, in which 
case the capability description must remain schema valid. 

5.3 Web Services Inspection language (WS-lnspection) 

A TV-Anytime web server may declare the presence of its metadata services using WS -Inspection [17]. This allows 
clients to discover service descriptions (i.e. WSDL implementation definitions) for the web services available on that 
website. The WS-lnspection file may also lead to the discovery of other types of web services, as well as TV-Anytime 
metadata services available on other web sites. 

It is recommended that each description element use a WSDL extensibility reference in the following fashion: 

• The endpointPresent attribute should be set to "true" (since a client is looking for existing services, and 
not abstract service definitions). 

• An implementedBinding element should be included for each port Type offered by the 
TV-Anytime service. In this way, the client can establish whether the corresponding service actually offers 
TV-Anytime ports and, if so, which port Types are present, without having to download and parse the 
WSDL implementation description. 

An example WS-lnspection file, along with its corresponding WSDL implementation definition, can be found in 
annex B. 
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5.3.1 Discovering the WS-lnspection file 



To assist a client in finding a WS -Inspection file, clause 6.1, the WS -Inspection specification states that the document 
may have a well-known name (inspection. wsil) and be placed at a "common entry point" of the web-site. The term 
"common entry point" is vague, so TV-Anytime defines the following rules to make it easier for embedded clients to 
retrieve the WS -Inspection document: 

• A metadata service provided by a web server with machine name <hostname>, which wishes to provide a 
WS-lnspection file, should place the document at the root of its web server. Thus, an HTTP GET request to 
http://<hostname>/inspection.wsil will retrieve the file if it exists. 

• A resolution authority with the name <domain_name>;<extension_name>, which wishes to provide a 
WS-lnspection file, should place the document at the location 

http://<domain_name>/<extension_name>/inspection.wsil. Note that this does not necessarily mean that the 
web server with the same domain name as the resolution authority has to also provide the metadata service 
since it is possible that the WS-lnspection document points to a URL on a different server. 
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Annex A (informative): 
Example usage of UDDI 

A.1 Example publication of get_Data operation 

The metadata service provider registers the new operation using the UDDI save_binding publication API 
(assuming that the appropriate parent businessEntity and business Service structures have already been 
registered). 

<save_binding xmlns="urn : uddi-org : api_v3"> 
<bindingTemplate> 

<description xml : lang="en">TV-Anytime movie inf ormation</description> 
OccessPoint useType="endPoint "> 

http : //barry-norman . com/movies</accessPoint> 
<tModelInstanceDetails> 

<tModel Instance Info tModelKey="uddi : TV- Any time . org: get_Data_vlO"> 
<instanceDetails> 

<instanceParms>< ! [CDATA[ 

<?xml version=" 1 . 0" encoding="utf-8 " ?> 

<describe_get_Data_Result serviceVersion="3 " 
xmlns="urn : tva :transport:2004"> 
< ! -- etc. See example 3 in Annex D --> 
</describe_get_Data_Result> 
] ] ></instanceParms> 
</instanceDetails> 
</ tMode 1 In stance In fo> 
</tModelInstanceDetails> 
<categoryBag> 

<keyedRef erence tModelKey="uddi : TV-Anytime . org : authorityName" 

keyValue="barry-norman . com" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : genre" 

keyValue="urn:tva:metadata:cs :FormatCS : 2 004 :3.3"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

key Va lue=" Content Re f erencing" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

keyValue="ProgramInf ormation" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 
keyValue="ProgramReview" /> 
</categoryBag> 
</bindingTemplate> 
</save_binding> 

The bindingTemplate structure contains a reference to the tMode 1 for the get_Data operation. In this way, 
the tMode 1 behaves as a technical fingerprint that formally indicates the TV-Anytime compliance of the web service. 

The categorization information allows a client to establish the following: 

• Metadata is provided on CRIDs from the "barry-norman.com" resolution authority. 

• Most of the programmes described by this metadata service have the "movie" genre. 

• The metadata service can return ContentReferencingTable, ProgramlnformationTable, and 
ProgramReviewTable elements. 
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A.2 Example search for TV-Anytime Metadata service 

Consider the example of a newly purchased PDR trying to create an enhanced EPG. The PDR wishes to display 
information on a known set of content service URLs (which happen to be DVB locators, obtained from DVB service 
information). To enable the construction of an EPG, the metadata service will need to offer a get_Data operation 
that is capable of delivering at least a ProgramLocationTable and Programlnf ormationTable. The 
following search could be used to find appropriate bindings. 

<f ind_binding xmlns="urn : uddi-org : api_v3"> 
<tModelBag> 

<tModelKey>uddi : TV-Anytime . org : get_Data_vlO</tModelKey> 
</tModelBag> 
< cat e gory Bag> 

<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.a"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.b"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.c"/> 
<! — Etc for other DVB locators — > 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

keyValue=" ProgramLocationTable" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 
keyValue=" Programlnf ormationTable" /> 
</categoryBag> 
</f ind_binding> 

The data structure returned to the device will contain a list of bindingTemplate elements that satisfy the above 
query. The list can then be refined by the user (based on brand preferences, recommendations, languages used, etc.), or 
automatically by the PDR (based on the capability description, and other taxonomies provided in 
eachbindingTemplate element). 

TV-Anytime clients may also register their interest in a particular type of metadata service, by registering with a node 
using the subscription API (see clause 5.5 of the UDDI specification [16]). In this case, the same f ind_binding 
element above could be used in the subscriptionFilter of the subscription message, thus defining the types of 
services that the PDR is interested in being notified about. 
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Annex B (informative): 

Referencing a WSDL implementation description using 

WS- Inspection 

The following WS-Inspection file contains a reference to a TV-Anytime metadata service providing both a get_Data 
and submit_Data port. 

http://example.com/inspection.wsil 

-(inspection xmlns="http : //schemas . xmlsoap .org/ws/2 001/10/inspection/" 

xmlns : wsdl="http : //schemas . xmlsoap . org/ws/2001/10/inspection/wsdl/ " 
xmlns : tva="urn : tva : transport : wsdl : 2004 "> 
<service> 
<de script ion ref erencedNamespace="http : //schemas . xmlsoap .org/wsdl/" 
location="http : //example . com/TV_week/tva_TV_week . wsdl"> 
<wsdl : reference endpointPresent="true"> 
<wsdl : implementedBinding>tva : get_Data_SOAP</wsdl : implementedBinding> 
<wsdl : implementedBinding>tva : submit_Data_S0AP</wsdl : implementedBinding> 
</wsdl : ref erence> 
</de script ion> 
</service> 
</inspection> 

The location attribute in the above description allows a client to download a WSDL implementation description. 

http://example.com/TV_week/tva_TV_week.wsdl 

< definitions targetNamespace="http : //example . com/ tva" 
xmlns : tva="urn : tva :transport:wsdl:2004" 
xmlns : soap="http : //schemas . xmlsoap . org/ wsdl /soap/ " 
xmlns = "http : //schemas . xmlsoap . org/wsdl/ "> 
< import name space=" urn : tva : transport : wsdl : 2004 " /> 
<service name="TvaThisWeek"> 

<port name="get_Data_TV_Week" binding="tva : get_Data_SOAP"> 

<soap : address location="http: //example . com/tv_week" /> 
</port> 
<port name="submit_Data_TV_Week" binding="tva : submit_Data_SOAP"> 

<soap : address location="http: //example . com/tv_week" /> 
</port> 
</service> 
</definitions> 



The referenced WSDL implementation definition is simple, and allows a client to establish the URL of the two 
TV-Anytime ports. Also, the technical version of the port is indicated via the namespace of the fully qualified binding 
name. 



ETSI 



23 ETSI TS 1 02 822-6-2 V1 .3.1 (2006-01 ) 



Annex C (informative): 
Bibliography 

Documents are available from the TV- Anytime web site http://www.TV-Anvtime.org . 
XML, Extensible Markup Language (XML) 1.0, October 2000. 

NOTE: Available at: http ://w w w. w3 .org/TR/2000/REC-xml-2000 1 006 . 
Namespaces in XML, W3C Recommendation, 14 January 1999. 

NOTE: Available at: http://www.w3.org/TR/REC-xml-names/ . 
IETF RFC 1945: "Hypertext Transfer Protocol, HTTP/1.0". 
IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 
IETF RFC 2616: "Hypertext Transfer Protocol, HTTP/1.1". 
Simple Object Access Protocol (SOAP) 1.1, W3C Note, 8 May 2002. 

NOTE: Available at: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ . 
Unicode Collation Algorithm, Unicode Technical Report #10. 

NOTE: Available at: http://www.unicode.org/unicode/reports/trlO . 
Unicode Normalization Forms, Unicode Standard Annex #15. 

NOTE: Available at: http://www. unicode.org/unicode/reports/tr 1 5 . 
Web Services Description Language, Version 1.1, W3C Note 15 March 2001. . 

NOTE: Available at: http://www.w3.org/TR/2001/NOTE-wsdl-20010315 . 

XML Schema, W3C Recommendations (version 20010502). 

NOTE: Available at: http://www. w3.org/TR/2001/REC-xmlschema-0-200 1 0502 , 
http://www.w3.org/TR/2001/REC-xmlschema-l-20010502 , 
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502 . 

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. 

NOTE: Available at: http://www.w3.org/TR/P3P/ . 
The WS-Inspection and UDDI Relationship, W. A. Nagy, K. Ballinger. 

NOTE: Available at: http://www-106.ibm.com/developerworks/webservices/library/ws-wsiluddi.html . 

Requirements and Scenarios for the Bi-directional Transport of Metadata, TV150rl. 
The TV-Anytime Forum. 

NOTE: Available at: http://www.TV-Anytime.org . 
IETF RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels". 
TV-Anytime Requirements Series: R-l, TV035r6. The TV-Anytime Forum. 

NOTE: Available at: http://www.TV-Anytime.org . 



ETSI 



24 ETSI TS 1 02 822-6-2 V1 .3.1 (2006-01 ) 



List of figures 

Figure 1: The steps in using a TV-Anytime metadata service 10 

Figure 2: Client requesting metadata from a metadata service 11 

Figure 3: Client submitting user-centric data to a service provider 12 



ETSI 



25 



ETSI TS 102 822-6-2 V1.3.1 (2006-01) 



History 



Document history 


VI. 1.1 


October 2003 


Publication 


Vl.2.1 


September 2004 


Publication 


VI. 3.1 


January 2006 


Publication 















ETSI 



